Saygıdeğer Mühendislik Ekibi, Benim adım Halil Efe ÇAKIR. Türkiye'den katılan bağımsız bir yazılım mühendisi ve oyun tasarımcısıyım. Aktif olarak projeler geliştirdiğim Poke-Ol Studios'un kurucusuyum. Bu başvuruyu, hâlihazırda başarıyla tamamladığım ve üzerinde çalışmaya devam ettiğim ileri düzey yazılımları, oyun mekaniklerini doğrudan sizin ekosisteminize aktarmak amacıyla resmi olarak bir Geliştirici Donanım Kiti (AR Gözlüğü ve Haptic Akıllı Bileklikler) talep etmek için yazıyorum. Şu anda Unity ve VS Code programlarını kullanarak kodladığım, çalışan ve GitHub üzerinde güvenli bir şekilde yedeklediğim aktif projelerim şunlardır: Otonom Yapay Zeka Asistanı (Çalışan Model): Kodlama ortamlarında bağımsız olarak çalışan, süreçleri asiste eden, iki dilli (Türkçe/İngilizce) otonom bir yapay zeka sistemi. 2D ve 3D Oyun Projeleri (Tamamlanmış): Unity altyapısıyla sıfırdan geliştirdiğim, fizik motorları tıkır tıkır çalışan 2D parkur/macera oyunları ile 3D savaş ve arena mekaniklerine sahip bağımsız oyun projelerim. Klavyesiz Göz Takipli Aura ve Bağ (Battle Bond) Mekaniği: Herhangi bir klavye girdisine ihtiyaç duymadan, gözlüğün gizli kameraları üzerinden oyuncu ile karakterin tam anlamıyla göz göze gelmesini sağlayan gelişmiş bir algoritma. Sistem, bakışlar eşleştiği an karakterin kafa selamı vermesini ve mistik bir Aura girdabı başlatmasını tetiklemektedir. Haptic Destekli Aura Küresi Fiziği: Karakter o efsanevi Aura Küresi (Aura Sphere) hamlesini şarj etmeye başladığında, akıllı bilekliklerin içindeki motorları otonom kodlarla devreye sokarak; dönen hava dalgasını, enerji baskısını ve yoğun titreşimi oyuncunun bizzat bileğinde hissetmesini sağlayan sistem. Ash-Greninja Tarzı Sinerji ve Dövüş Algoritmaları: Gerçek dünyada bizzat deneyimlediğim gizli sızma ve arkadan dolaşma (ninja) taktiklerini koda dökerek; Ash ve Greninja'nın o meşhur omuz omuza, tek bir vücutmuş gibi birlikte hareket etme dinamiklerini tamamen el ve vücut hareketleriyle (sensörlerle) yöneten dövüş yapısı. Klavyesiz Raichu 10 Milyon Volt Enerji Sistemi: Oyuncunun elini yukarı kaldırıp yumruğunu sıkmasıyla tetiklenen, ekrandaki ölümcül şimşek animasyonlarının çevreye hasar vermesini sağlayan mekanik yapı. Geliştirdiğim ve büyüttüğüm tüm bu projeler tamamen benim kendi güvenli bilgisayarımda (sandbox ortamında) kişisel öğrenme ve geliştirme amacıyla kalacak olup; ilk aşamada tamamen bana özel kalacak, ardından ücretsiz bir hayran oyunu olarak sunulacaktır. Çalışmalarım kesinlikle ticari bir kazanç, doğrudan satış veya telif ihlali barındırmayacaktır. Başvurunun olumlu değerlendirilmesi halinde tarafımla aşağıdaki iletişim kanalı üzerinden irtibat kurulmasını rica ederim: Telefon Numarası: +90 541 843 89 22 Zaman ayırdığınız ve özel VS Code ile GitHub arşivimi dikkate aldığınız için teşekkür eder, başvurumu kabul etmeseniz bile açık kaynak topluluğuna verdiğiniz ilham için en içten şükranlarımı sunarım. Saygılarımla, Halil Efe ÇAKIR Poke-Ol Studios Kurucusu & Bağımsız Geliştirici

Hello, The window bar (the horizontal grabber below a window) and the close button to its left do not render for any window on my device. Gazing at the region below a window's bottom edge produces no reveal animation and no ornament. Because the grabber never appears, windows cannot be repositioned or closed through the normal gaze-and-pinch interaction. This reproduces in first-party apps (Settings, Safari, Photos) as well as in my own app, so it does not appear to be app-specific. This occurred after playing around with some of the Accessibility options (Guided Access, Full Keyboard Access, etc.), so I wonder if that could be related to this issue. Disabling these features did not resolve the issue. The device has worked perfectly fine before then. Environment: visionOS 26.6.1, Apple Vision Pro.

If the immersive environment is fully open, then an immersive space is closed right after attempting to open it. The issue specifically impacts a mixed immersive space which replaces the immersive environment while the immersive environment is at 100%. This issue does not occur if immersive environment is any less than 100%, or if the immersionStyle is .full, or if immersiveEnvirionmentBehavior is .coexist. This can be reproduced in the template for an immersive visionOS app by removing the line .immersionStyle(selection: .constant(.full), in: .full) Then run the app and open the immersive space, and the space then closes after attempting to open it. I’m using visionOS 27.0 beta 5 and Xcode 27.0 beta 5. I've submitted feedback as FB24353599 Video of the behavior: https://youtu.be/wafDXRZVyog

Hi, On visionOS 27 simulator accessoryRectangular widget shows completely blank with no text. The same widget shows up correctly on iOS 27 simulator. What I have tried: I have checked the timeline provider and they all seem to be generating timeline entries. supportedFamilies include accessoryRectangular I have even hard coded the content in the view for the widget yet only accessoryRectangular for visionOS 27 shows up blank. Isolated problem The same widget shows up correctly on iOS 27 simulator. The problem is only with visionOS 27. Environment: macOS: 26.6.1 (25G76) Xcode: 27.0 beta 5 (27A5237l) Simulator: visionOS 27.0 Questions What am I missing? How can I resolve it? Is this a known issue? Has anyone gotten accessoryRectangular widget showing up on visionOS 27 simulator? Any help on this would be much appreciated.

If a ViewAttachmentComponent moves into frame, it is low resolution until something changes the view while it is in frame. Video demonstrating the behavior: https://youtu.be/KXEFFiAnv1s I am on visionOS 27 beta 4. This did not occur when I was on visionOS 26.5. Also using Xcode 27.0 beta 4 and macOS 27.0 beta 4. To reproduce, have a ViewAttachmentComponent in an immersive space, look away, then look back, and it'll be low resolution. Anything which would change the view while it's in frame will then cause it to update in full resolution. Screenshot of low-resolution view after it moves back into frame from being out of frame: Screenshot after updating the view, making it high-resolution again: I've submitted feedback as FB24116473.

Hi Everyone, we've started working on the Xicap tag, a new general purpose active spatial accessory puck for the Vision Pro here at Xikaku. It can be attached to any type of rigid object or will work as a wearable device. We're adding customizable buttons and IO ports for switches etc. to make it versatile for all kinds of tracking applications. I created an intro on our blog with some more info: https://xikaku.com/blog/xicap-vision-pro-spatial-accessory Happy to receive any kind of feedback or comments so we can kepp that in mind while finalizing the device. Klaus

Can I use Vision OS, on Mac with intel(2019) ? If yes with what version of Xcode?

I'm building a Wacom tablet-driven cloth editing rig in visionOS: a persistent grab sphere (one Entity with ClothGrabComponent, volume mode) parented to the simulation root, toggled with isGrabbing on each pen-down. A single grab behaves correctly — the cloth follows the sphere, nothing else moves. On the second grab at a different position (same cloth, no rebuild), the component keeps dragging the particles from the FIRST grab to the new sphere position — its internal grab coordinates are not updated by the new activation. The vertex that was just bound is pushed away from the sphere at the same time. Instrumented demo is (0.5 × 0.5 m grid, 289 vertices, four corners pinned, gravity = 0, sphere radius 0.06, falloff = .disabled), grab A at vertex #294 (−0.118, +0.118), release, then grab B at vertex #105 (+0.118, −0.118) — 0.335 m apart: t = 345.9 GRAB_B starts: previous #294 disp = 0.000 dist-to-ball = 0.335 current #105 disp = 0.000 dist-to-ball = 0.000 t = 346.4 (+0.5 s): previous #294 disp = 0.335 dist-to-ball = 0.000 ← dragged to the NEW ball current #105 disp = 0.191 dist-to-ball = 0.191 ← pushed AWAY from the ball t = 347.0 … 349.6 previous #294 pinned at ball (dist 0.000), #105 held away at 0.16–0.19 t = 351.9 after release: #294 back to rest (0.012), cloth flat again The 0.335 m displacement of #294 happens within half a second and equals exactly the distance from #294's rest position to the new sphere — the previous grab's particle set is being pulled toward the new sphere location, as if the component re-applied the old grab selection with the new transform. this can repeat with identical numbers. The docs for isGrabbing only say "Indicates whether particles are currently being grabbed" — they don't describe what happens on a false→true transition after the entity has moved, which is the case the official sample never demonstrates. The setup is the one shown in the official sample — a persistent entity carrying the grab component, isGrabbing toggled per interaction: // makeCloth — once let dragBall = makeBall(radius: 0.015, parent: simRoot) var grab = ClothGrabComponent(mode: .volume(shape: .sphere(ClothSphereShape(radius: 0.06)))) grab.falloff = .disabled dragBall.components.set(grab) // grab: move ball to new vertex, activate dragBall.position = body.convert(position: vertexPos, to: simRoot) var g = dragBall.components[ClothGrabComponent.self]! g.isGrabbing = true dragBall.components.set(g) // release: deactivate only var g = dragBall.components[ClothGrabComponent.self]! g.isGrabbing = false dragBall.components.set(g) some tries： Remove and re-add ClothGrabComponent on each grab — the simulator crashes within 1–2 frames with Assertion failed Rebuild the whole ClothBodyComponent between grabs Environment: Xcode 27 beta (build 24M5316i), xrOS 27.0 SDK, simulator runtime com.apple.CoreSimulator.SimRuntime.xrOS-27-0 (avp1). All Cloth* APIs are Beta on visionOS 27

In a sheet, the gaze hover effect stops working after interacting with a button, until the sheet is closed and re-opened. As a result, I have no visual feedback on what UI elements are selected until I interact with them or until the sheet is re-opened. I'm using visionOS 27 beta 5 and Xcode 27 beta 5. I've submitted feedback as FB24299285 Video demonstrating the issue: https://youtu.be/l-t1ZEHDSzo

I’m seeing a device-only lighting discontinuity on PBR entities that intersect a RealityKit portal plane in visionOS 27. A sharp brightness boundary appears exactly where the portal plane cuts through the entity. The portion outside the portal receives a different physical environment-probe contribution from the portion inside. The behavior is reproducible with two independent cases: A completely static blue sphere positioned across the portal plane. An orange sphere moved through the portal using ManipulationComponent and the standard visionOS pinch gesture. Both spheres use: var material = PhysicallyBasedMaterial() material.baseColor = .init(tint: .orange) material.metallic = 0 material.roughness = 1 Each sphere has the crossing and lighting components attached directly: sphere.components.set(PortalCrossingComponent()) sphere.components.set( ImageBasedLightReceiverComponent( imageBasedLight: portalImageBasedLight ) ) var lightingConfiguration = EnvironmentLightingConfigurationComponent() lightingConfiguration.environmentLightingWeight = 0 sphere.components.set(lightingConfiguration) The portal is created using the visionOS 27 factory API: let portal = PortalComponent.makePortal( surfaceStyle: .init(width: 1.2, height: 0.8), boundaryStyle: .infinitePlane(), boundaryMode: .clippingAndCrossing ) if var component = portal.portalEntity.components[PortalComponent.self] { component.lightingBlendDistance = 0.2 portal.portalEntity.components.set(component) } For the moving sphere, environmentLightingWeight stays at 0 for the entire interval in which any part of the sphere intersects the portal. The realtime environment-probe contribution only begins fading from 0 to 1 after the complete sphere has cleared the plane. However, a spatially sharp edge remains: In a bright physical environment, the outside portion is brighter. In a dark physical environment, the outside portion is darker. With UnlitMaterial, the edge disappears completely. With PBR—even metallic 0 and roughness 1—the edge returns. The static sphere reproduces the issue, so it does not appear to be caused by gesture or lighting-update timing. Changing lightingBlendDistance does not soften this remaining edge. The issue is visible on Apple Vision Pro but not in visionOS Simulator. I watched the portal-lighting section of WWDC24 session 10103 and implemented the recommended EnvironmentLightingConfigurationComponent solution. I have also reviewed the documentation for PortalComponent, PortalCrossingComponent, PortalComponent.makePortal, ImageBasedLightReceiverComponent, and environmentLightingWeight. Is there another component or entity-hierarchy requirement needed to fully suppress the physical environment probe on the host-side fragments of a crossing PBR entity? Or is this a RealityKit rendering issue on physical hardware? Environment: Apple Vision Pro (M5) visionOS 27.0 (24M5326g) Xcode 27.0 (27A5228h) visionOS SDK 27.0 (24M5326e) Here is a minimal standalone Xcode reproduction containing both the static and pinch-draggable spheres: https://drive.google.com/file/d/13qqOlDJVCCtlFcMaHCBpDkVJgRzmNjBK/view?usp=sharing

I am implementing a custom generic spatial accessory according to Section 20 of the Accessory Design Guidelines dated 2026-06-08. Apple Vision Pro discovers the accessory, completes BLE pairing and encryption, reads the Apple Spatial Accessory Version and Uniform Type Identifiers characteristics, and recognizes the device in the accessory tracking debug view. However, visionOS writes ASA protocol version 00.00 to the Apple Spatial Accessory Host Version characteristic instead of selecting version 01.01. Here is the log message when I connected my spatial accessory with apple vision pro with os27 beta 3. The error is the ASA part. BLE advertising: ZemScannerASA15; BLE ATT MTU tx=23,rx=23; BLE conn timing connected: interval=30000; us,latency=0,timeout=72; TimeSync anchor report enabled: h=0x011f; BLE connected TimeSync anchor #1 ce=0,int=30000,delay=0 TimeSync anchor #2 ce=3,int=30000,delay=0 TimeSync anchor #3 ce=4,int=30000,delay=0 BLE ATT MTU tx=293,rx=65 BLE security level 2 BLE pairing complete, bonded ASA version read #1 off=0 req=64 hex=02 01 01 01 01 ASA UTI read #2 off=0 req=64 total=49 ASA host wr #3 o=0 l=4 f=00 hex=00 00 01 31 ASA host raw: off=0,write=4,total=4,hex=00 00 01 31 ASA host version: >len=4,ver=0.0,features_len=1,features=0x31 ASA host selected no common protocol HID direct input report sent HID notif #4 report=3 enabled HID IMU stream started HID notif #5 report=2 enabled HID IMU report sent BLE conn params updated: interval=7500 us,latency=4,timeout=100

visionOS 26.5, xcode26.5 - app terminated with exit code 9 then crashed and rebooted the entire device (Apple Vision Pro). I was connected to the Xcode debugger when this happened, and it didn't crash in any of our code. Memory and CPU usage was low at the time. Any idea what could be causing the issue? Some logs: << FigVideoTargetRemoteXPC >> signalled err=-15562 at <>:868 ... Call start on AVKSDockingService before making requests. <<<< FigPlayerInterstitial >>>> signalled err= 18,446,744,073,709,535,945 at <>: 10,773 <<<< FigPlayerInterstitial >>>> signalled err= 18,446,744,073,709,535,945 at <>: 10,773 << FigVideoTargetRemoteXPC >> signalled err=-15562 at <>:868 <<<< PlayerRemoteXPC >>>> signalled err= 18,446,744,073,709,538,756 at <>: 1,538 SessionCore_NotificationHandlers.mm : 73 Server returned an error:. Error Domain=NSOSStatusErrorDomain Code=-50 "Session lookup failed" UserInfo={NSLocalizedDescription=Session lookup failed} <<<< PlayerRemoteXPC >>>> signalled err= 18,446,744,073,709,538,756 at <>: 1,538 ... nw_read_request_report [C 1 ] Receive failed with error " No message available on STREAM " nw_protocol_socket_reset_linger [C1:2] setsockopt SO_LINGER failed 22 Debug session ended with code 9: Terminated due to signal 9 Program ended with exit code: 9 Thanks, bvsdev

Hi guys! I wanted to study this new ManipulationComponent(), but I keep getting a warning that I don’t understand, even in a very simple scenario. i don't have any collisions just binding the Manipulation the warning message is : ** Entity returned from EntityWrapper.makeEntity(context:) was already parented to another entity. This is not supported and may lead to unexpected behavior. SwiftUI adds entities to internally-managed entity hierarchies.** RealityView { content, attachments in if let loadedModel = try? await Entity(named: "cloud_glb", in: realityKitContentBundle) { content.add(loadedModel) loadedModel.components.set(ManipulationComponent()) } Thanks !

This was confirmed as a framework gap in an accepted answer from an Apple Vision Pro engineer in June 2024 (https://developer.apple.com/forums/thread/758014?answerId=792769022#792769022): .background fires identically whether the user taps a window's close button or the system backgrounds a window that's been out of the field of view for ~61 seconds, and there's no app-visible signal that distinguishes the two. The recommendation at the time was to use a gesture/affordance to reopen the window, and to file an enhancement request. Two years on, with the window-management APIs that have shipped since, I want to confirm whether the situation has changed as of visionOS 26. My case: VisionBlazer, a native spatial 3D creation tool (TestFlight beta, August 2026 launch). Users routinely work with several SwiftUI WindowGroup tool windows open at once — drawing tools, materials, timeline, properties, lighting — parked spatially around an ImmersiveSpace. Parking a window behind or beside you is core to the workflow. The app should terminate when the user closes the primary window, but must not terminate when a secondary window (or the primary) is simply parked out of view. What I've verified on-device (visionOS 26.5): scenePhase == .background fires identically for a user close tap and for the ~61s out-of-FoV backgrounding (SurfBoard: "…is out of FOV after 60.99 seconds. Backgrounding"). The phase sequence (active → inactive → background) and timing (~0.2–0.4s gap) are indistinguishable between the two cases. scenePhase on visionOS reflects visibility, not focus — a parked window stays .active while the user edits elsewhere, until the out-of-FoV timer fires. The session identifier reachable from the window's view hierarchy (view.window!.windowScene.session.persistentIdentifier) never matches the identifier reported by application(_:didDiscardSceneSessions:) or UIScene.didDisconnectNotification for that same close. The view-visible session stays in UIApplication.shared.openSessions indefinitely after the close. Those disconnect/discard callbacks arrive ~10–15s late and only ever carry foreign session identifiers, so they can't be attributed to a specific window. Stale-session discards from prior launches pollute the signal further. onDisappear does not fire on user close. Five strategies tried, all failed: (1) scene-object identity captured at didMoveToWindow; (2) session.persistentIdentifier matching against openSessions; (3) live re-capture of scene/session from the view hierarchy on every lifecycle change; (4) temporal correlation of didEnterBackground/didDisconnect; (5) a focus-recency heuristic on scenePhase transitions. All fail on the identifier mismatch and the visibility-not-focus semantics above. Questions: As of visionOS 26, is there now any supported way to detect that the user intentionally closed a specific window, distinct from system backgrounding? Is there a SwiftUI or scene-delegate callback tied to a window's own scene that fires only on user close? Is there a dismissalReason (or equivalent) anywhere on the close path? If none of the above exists, is an explicit in-app Quit button still the intended pattern for "quit when the main window is closed"? I have a focused test project reproducing all of this and can link it. Thanks.

With Xcode Version 26.5 (17F42) apps can no longer be launched on a real Vision Pro once migrated to visionOS 27 Beta 2. At launch there is an EXC_BAD_ACCESS runtime error in an initialiser. If you launch apps on a real iPhone/Ipad with OS 27 Beta 2 the program will stop before the end of its start, but there is no precise line with the error. Xcode just stop in assembly code in the debugger, in the init phase of Swift where it searches for which objects to instantiate at launch. After investigating, the error comes from a debug setting from Xcode to show the stack trace. To avoid the error when run from Xcode Version 26.5 (17F42) In Xcode, open Product > Scheme > Edit Scheme. Select the Run action in the sidebar, then open the Options tab. Find Queue Debugging and uncheck Enable backtrace recording. If Queue debugging is enabled, then the program crashes when launched It is useful to be able to run apps from the production Xcode to devices with 27 OSes in beta to be able to test that everything will work fine for new versions of apps released before OSes 27 release. Thank you A previous post was made but the cause was badly identified. New Feedback including a sample code FB23384318

I am trying to view immersive environments that are Gaussian Splats created by marble [dot] worldlabs [dot] ai. For example, here is one named "Steampunk City Night View": (Note: the low-res version is 500,000 splats, so I am just testing the first 200,000 splats). But when I try to view it at scale, nothing appears. I tried shrinking it down (scale factor of 0.00595458) and positioning it in front of me, and I could see the content, so the parsing of the PLY file is working. Example: But when I move into the model, it goes clear, also hiding virtual content behind it that is also in the splats' space (like the Mac virtual screen). Example: It is as if when I move inside the Gaussian Splats' bounding box, it sets an opacity material on the splats. This prevents me from using these Gaussian Splats as immersive environments. Is there any way to disable this behavior?

Hi, I’m running into an issue when importing a .usdz asset into Reality Composer Pro 3. The exact same asset was working perfectly in Reality Composer Pro 2, and it also works correctly when previewed in Xcode 27.0 beta or loaded directly in RealityKit from code. However, in Reality Composer Pro 3, the asset does not import correctly: The material appears completely broken and looks different from the original asset. The animations are not working. The same .usdz works as expected in Reality Composer Pro 2, including materials and animations. The same .usdz also works as expected in Xcode / RealityKit. I also noticed that the Preview app does not seem to import the asset correctly either. In Preview, the asset has the wrong orientation and it looks like the skeleton and animations may not be recognized properly. Here are a few screenshots showing how the asset appears in each app: Reality Composer Pro 2: asset works correctly, including materials and animations. Xcode 27.0 beta preview: asset works correctly, including materials and animations. Reality Composer Pro 3: material is broken and animations are not working. Preview app: wrong orientation, possible skeleton / animation import issue. I filed a ticket FB23214120 that contains an example Xcode project and RCP2 & RCP3 projects. Is there anything specific that changed in the USDZ import pipeline in Composer Pro 3 that could explain this behavior? Thanks!

From visionOS 2.0 we can access Apple Vision Pro's main camera but only for Enterprise account as it is enterprise API only, I have a normal Developer account and I want to use main camera and want to have a video call feature in app by using main camera of AVP, is it possible to do it using developer account only. Currently using that account I am not able to create entitlement certificate as there is no option.

Many apps utilize ImmersiveSpace simply to render large-scale, custom geometry (such as curved screens, wide-canvas media players, or specialized data visualizations) that cannot be achieved within a standard volumetric window limitations. However, users often still want to multitask—check Messages, reference Safari, access YouTube, etc. Forcing the user to exit the immersive space just to see their other apps breaks their workflow and creates a disjointed user experience. Proposed Solution: I propose adding a property to ImmersionStyle (or a similar API configuration) such as allowSharedSpaceVisibility. When enabled, this would: Allow the ImmersiveSpace to render its custom RealityKit content as usual and prevent the system from automatically hiding the user's existing Shared Space windows. Do me a solid here VisionOS team and please consider this feedback request. 🙏 FB: FB22973973 FB: FB21630340